Currently, the traditional process flow for software application creation begins with coding in a software language. The coding involves laying out all executable commands, modules, sub-programs, etc., creating all the formatting for graphical display, and providing that which is to be displayed on the graphical user interface (GUI) as the software is running, including text and objects, for instance.
The coding is compiled, and then tested. A programmer or software engineer runs through all aspects of the program to ensure that the program operates as intended, as well as ensures that all displayed materials are shown as expected, including typographical errors, proper formatting, and consistency. For instance, while the software application itself (and compiler, etc.) would recognize improper coding of executable commands and return an error statement when running or compiling, the only manner in which a typographical error is detected is by displaying the text on the GUI and a software engineer recognizing the error.
Additionally, as a single application may be constructed partly or entirely with re-usable modules built at different times by many different people, there may be inconsistencies in textual usage. Specifically, a particular module may have been built using a text string “Start,” while a second module used in the same application may use a text string “Begin.” Typically, a software provider would like each of these to be the same. It is during testing and running that these may be noticed.
During testing, the software engineer may have a hard-copy of the code on hand, and make hand edits on the hard-copy. The source code is then accessed and each of the revisions is addressed by altering or correcting the code and, in particular, the text strings. The program is then re-compiled and run again. As can be seen, this is a long and tedious process.
Once the program is completed, it may be packaged and/or released. However, as is clear, the text strings are not assessed by anything other than a user/engineer for being proper. Specifically, the application itself (or host machine) does not assess whether the person viewing the text is actually viewing information that conveys the intended message. More specifically, a computer does not recognize that a program built with text strings in a particular human language, such as English, are properly understood by a user who speaks Chinese or Russian, for instance.
Therefore, a process known as internationalization must be performed for the text strings. There are a number of traditional internationalization methods, including examining the source code line-by-line for translation, or a user may run the program and make notes regarding the necessary translation.
In an improved method of internationalization, all the textual content of the source code may be identified and collected to allow a program, as a first translation step, to extract and translate the text strings. A problem with this method is that much of the source code is also written with characters that are identified as text and should not translated. Often, this leads to inadvertent translation of source code commands, and compiling the application will then fail or return an error on running.
A number of improved methods for editing software have been devised to simplify the process of textual edits. For instance, U.S. Pat. No. 6,735,759, to Yamamoto, et al., describes an editing system for translating text. The '759 patent notes the problem of translations made when the text is extracted from the application and, thus, not displayed in context. The result is that, when a plurality of words may be selected, an improper selection may be made that is not recognized until the text is displayed during running of the application. While a number of forms are described, the '759 patent generally teaches an introspective editor built into the software application itself and running at the same time. In response to engineer interaction, the editor provides a pop-up window containing text to be edited. The text may be altered or re-written to provide a new text string that is then stored in a localization file for future use.
However, the '759 patent has a number of deficiencies. First of all, all the edits are stored “for future use.” In other words, software application does not recognize the change until the application is re-started and, thus, the changes are not viewable until such happens. Therefore, any other users (such as distributed users accessing the software on a host network machine from user terminals) will not see any of the changes until the program is restarted from the host machine. Furthermore, the editor function relies on introspection which itself relies on very specific naming conventions in a resource bundle to properly identify the text string to be edited. This results in greater demands placed on software engineers/programmers at the initial build stage, and existing modules that otherwise could be used must be re-coded to conform to the conventions necessary for introspection. Lastly, the '759 patent provides a separate resource key, for instance, for every text string that may displayed by the application, the result being that every instance of text that is to be translated, for instance, must be individually changed.
Accordingly, there has been a need for an improved software editor for editing text to be displayed on a graphical user interface.